@bors2 try @rust-timer queue

@bors try cancel

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/19147789788

@bors2 try @rust-timer queue

@bors try cancel

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/19148135975

@bors2 try @rust-timer queue

Btw, you don't need to cancel the previous try build when making a new one. Bors will automatically cancel the previous one.

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

[RUSTC-TIMING] rustc_demangle test:false 1.214
error: missing documentation for a method
    --> library/alloc/src/string.rs:1117:5
     |
1117 |     pub fn push_str_slice(&mut self, slice: &[&str]) {
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: `-D missing-docs` implied by `-D warnings`
     = help: to override `-D warnings` add `#[allow(missing_docs)]`

☀️ Try build successful (CI)
Build commit: 978d49e (978d49ebec63bc482a297308eb28bd9bfff55fb6, parent: c90bcb9571b7aab0d8beaa2ce8a998ffaf079d38)

Huh. CI failed but the try build didn't, is this another case of a check only being run in CI, or did something about bors change so that perf can continue even if there's an issue?

Finished benchmarking commit (978d49e): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Cycles

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 475.185s -> 474.535s (-0.14%)
Artifact size: 390.81 MiB -> 390.80 MiB (-0.00%)

It's a very slight improvement by every metric, including artifact size, surprisingly. I think I might open an ACP for push_str_slice, it's not a huge improvement, but it's basically free for any code that builds strings in this manner, and I do suspect there's probably some user who is doing this in a hot inner loop and would appreciate saving some cycles (i saw around a 30% improvement in local microbenchmarks vs just calling push_str twice, probably relevant for some serialization code).

The default try build just builds the compiler, and doesn't run any tests. So often it succeeds even if CI fails, it's by design.

FWIW, the artifact size is noise, and the icount results are a wash. It doesn't seem to me that this has an effect.